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(54) Quality of service (QoS) enhancement to multilink point-to-point protocol (PPP) 

FIG. 4 



(57) Multilink PPP is enhanced to provide for a more 
flexible quality of service (QoS) support in a wireless 
environment. In particular, multilink PPP is enhanced to 
enable a packet interface, or packet endpoint, to trans- 
mit a message to an opposite PPP peer, where the 
message identifies the number, and type, of classes on 
a particular PPP link. Two new messages are defined 
for use in the IP control protocol (IPCP) phase of a mul- 
tilink PPP connection: a "non-Sharing QoS Negotiation" 
option message, and a "QoS-Enhanced Multiink 
Header Format" option message. 
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Description 

CROSS-REFERENCE TO RELATED APPLICATIONS 

[0001] Related subject matter is disclosed in the co- 
pending, commonly assigned, U.S. Patent application of 
Chuah, entitled "Providing Quality of Service in Layer 
Two, Tunneling Protocol Networks," serial No. 
09/259900, filed on February 26„ 1999. 

BACKGROUND OF THE INVENTION 

(1) FIELD OF THE INVENTION Y 

[0002] This invention relates generally to communi- 75 
cations and, more particularly, to packet communica- . 
tions systems. 

(2) BACKGROUND ART 

20 

[0003] CDMA (carrier division multiple access) 
packet data service represents one method of providing 
wireless data services to mobile users over Internet 
Protocol (IP) based networks (e.g., see Toni. Hitler. 
"Wireless IP Network Architecture based on IETF Pro- ' 25 
tocols", TR45.6-3G/99.05.17.06). In TR 45.6, the point- ' 
to-point protocol (PPP)'is used as the link layer between 
a mobile terminal, or mobile node (MN) and a Packet 
Data Serving Node (PDSN). 

[0004] It has been proposed to enhance PPP to 30 
provide quality of service (QoS) features. One proposal 
is "real-time framing" (e.g., see C. Bormann, "PPP in a 
real-time oriented HDLC-like framing", work in progress, 
(draft-ietf-isstl-isslow-rtf-05.txt), April 1999). Another 
approach is "multiclass multilink PPP" "(e.g., see C. 35 
Bormann, "The Multiclass Extension to Multilink PPP", 
work in progress, (draft-ietf-issll-isslow-mcml-06.txt), 
June 1999). 

[0005] Unfortunately, both these modifications are 
not well -suited to wireless access networks. For exam- 40 
pie, real-time framing is not sufficient because the PPP 
peers are only aware of any different classes of service 
when bearer traffic appears on the receiving interface. 
However, for a wireless access network this information 
is needed to decide which type of wireless link to acti- 45 
yate - before bearer traffic appears. With respect to mul- 
ticlass multilink PPP, "this approach fragments each 
. packet for transport across multiple links. In addition, 
multiclass multilink PPR while specifying the maximum 
number of classes for a multilink PPP session, does not so 
specify the class definitions. 

SUMMARY OF THE INVENTION 

[0006] Multilink PPP is enhanced to provide for a 55 
more flexible quality of service (QoS) support in a wire- 
less environment. In particular, and in accordance with 
the invention, multilink PPP is enhanced to" enable a 



packet interface, ! or packet endpoint, to transmit a mes- 
sage to an opposite PPP peer, where the message 
identifies the number, and type, of classes oh a particu- 
lar PPP link. 

[0007] In an embodiment of the invention, multilink 
PPP is modified to support a. "non-Sharing QoS Negoti- 
ation" option message, and a "QoS-Enhanced Multilink 
Header Format" option message during the IP control 
phase. 

PTION OF THE DRAWING 



FIG. 1 shows an illustrative wide area wireless data 
network; 

FIG. 2 shows illustrative protocol stacks for use in 
the network of FIG. T for providing IP services to 
mobile users; 

~ FIG. 3 shows an illustrative format for a new "Non- 
Sharing QOS" option in accordance with the princi- 
ples of the invention; • 
: ' FIG. 4 shows an illustrative multilink PPP negotia- 
tion where one PPP link uses the Non-Sharing QoS 
option in accordance with the principles of the 
invention; 

FIGs. 5, 6 and 7 show illustrative formats for a new 
"QoS-Enhanced Multilink Header Format" option in 
accordance with the principles of the invention; and 
FIG. 8 shows an illustrative high-level block diagram 
of a packet endpoint for use in performing multilink 
PPP negotiation in accordance with the principles 
of the invention. 

DETAILED DESCRIPTION 

[00Ci9] Before describing the inventive concept, a 
brief overview of iP-based wireless; data services is pro- 
vided. The following description utilizes third generation 
(3G) wireless terminology for network entities (e.g., see 
Tom Hulleretc, "3G Wireless Data Provider Architecture 
Using Mobile IP and AAA", draft-hiller-3gwireless-00.txt, 
March, 1999). 

[0010] FIG. 1 shows a generic wide area wireless 
data network reference model. The elements are well- 
known and win riot be described in detail. For example, 
the mobile endpoint or terminal equipment is repre- 
sented by mobile node (MN) 105. The latter registers 
with the closest base station, e.g., BS 1 1 0, via link-layer 
messages. For the purposes of this example, it is 
assumed that the BS 110 is a part of a "foreign area" 
served by Interworking Function Unit (IWF) 115 (which 
is basically equivalent to an Intermediate Foreign Agent 
(I FA) as known in the art). IWA 1 15 is coupled to a Vis- 
iting Packet Data Serving Node (V-PDSN) 120 (which is 
basically equivalent to a gateway foreign agent/dynamic 
' home agent (GFA/DHA) as known in the art). (It should 
be noted that, although not shown in FIG. 1 , the foreign 



protocol (IPCP) 
' J3RIEF DESCRII 
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area-comprises other IWFs, which can communicate 
with .one another.) Similarly, the user (not shown) of MN 
105 as associated with a "home area." The latter is rep- 
resented by Home Packet Data Serving Node (H-DSN) 
130 (which is basically equivalent to a gateway home 
agent) and home agent (HA) 135. It is assumed that 
well-known user authentication methods are used, e.g., 
via Authentication, . Authorization, Accounting (AAA) 
Servers 125 and 140. In this context, BS 110, (WF 1 15, 
V-PDSN 120, H-PDSN 130 and HA 135 are all different 
forms .of packet . servers. Communications between, 
e.g., V-PDSN 120 and H-PDSN 130, is via Internet Pro- 
tocol (IP)-based network 140. 

[0011] As noted above, wireless data services are 
provided .to the ujser associated .with MN 105 via the. IP- 
based network of FIG. 1. Since MN 105 is visiting with a 
foreign area, support of such mob,ile-IP services typi- 
cally requires that messages are "tunneled" from the 
home IP network to the foreign JP/ietwork for address- 
ing, and. routing purposes. Within, this .context, it is 
assumed that communication between -BS 1 1 0 and I WF 
1 15 takes place at the link -layer. ^ J ... 
[0012] . An . illustrative protocol ..stack g?ing the pro- 
posed TR45.6 architecture for providing s : uch IP serv- 
ices is shown in FIG. 2 (e,g., see. torn Hiller, "Wireless 
IP Network Architecture based on, IETF Protocols", 
TR45.6-3G/99.05.1 7.06). . In-, FIG. 2 JP represents the 
Internet Protocol layer,. PPP .represents, the point-to- 
point protocol layer, UM represents the logical link con- 
trol/medium access control layer,, WL represents tne 
wireless link layer 1 , and L1 represents. any link layer 1 
.-transport (the physical layer), BHIP L2 represents a 
back haul IP tunnel over link layer 2, and TIP l_2 repre- 
sents the core IP tunnel over link layer 2. As can be 
observed from FIG. 2, PPP is used as the link layer 
between the MN and the V-PDSN. The MN first regis- 
ters with the closest BS via link-layer messages. Then, 
a PPP session is activated between theJviN and the V- 
PDSN. Via .the PPP session set up procedures, the V- 
PDSN can assign an IP address dynamically to the MN. 
In addition, some layer 3 tunnel set up messages are 
exchanged between the V-PDSN and the H-PDSN such 
that a core IP tunnel (TIP) exists from the H-PDSN to 
the V-PQSN. This core IP tunnei is used to deliver pack- 
ets destined for the MN. Packets destined to the MN are 
intercepted by the H-PDSN. and delivered to the V- 
PDSN via the core IP tunnel. The V-PDSN in turn deliv- 
ers them.tothe appropriate IWF via the backhaul IP tun- 
nel (this assumes that the network between the V- 
PDSN and IWF is an IP network). (Note that this back- 
haul IP tunnel carries PPP frames, tunnel establish- 
ment protocols are known in the art .(e.g., see P. 
Calhoun, G. Montenegro, C. Perkins, "Tunnel Establish- 
ment Protocol," draft-ietf-mobileiprcalhoun-tep-01.txt, 
March 1 998).) The IWF then delivers' the packets to the 
appropriate base station, which, delivers them to the 
MN. Packets from the MN are similarly delivered from 
the base station to the IWF, which delivers them to the 



V-PDSN. If necessary, a reverse core IP tunnel is set up 
from the V-PDSN to the H-PDSN for use in delivering 
traffic from the MN to any host within the home network. 
If no reverse tunnel exists, the packets are delivered to 
5 the H-PDSN via regular IP routing (only if packets are 
J " destined for a host within the H-PDSN). (Note' that if the 
corresponding host does nof reside in the H-PDSN, one 
can just "use the V-PDSN as a dynamic home agent. In 
this mode, packets from any wired host to the MN are 
10 intercepted by the V-PDSN and routed to the MN. Simi- 
larly, any packets from the MN to any wired host are 
routed by the V-PDSN.) : 

[0013] The inventive, concept modifies muftilink 
PPP (e.g., see K. Slower etc, The PPP Muftilink Proto- 

15 col (MP)°, RFC 1990, August, 1996) and only that por- 
tion of multilink PPP relative to the inventive concept is 
described herein, i.e.," the "relevant portions of the IP 
control protocol (IPCP) phase. As such, familiarity with 
existing IP protocols is assumed., Further, it is presumed 

20 that a packet endpoint is suitably programmed to carry 
out the, below-described methods using conventional 
programming techniques, which, as such, will not be 
described herein.'. 
" [0014] "/ " An illustrative format for a hew "Non-Sharing 

25. Q0S* option. message is shown in FIG. 3. The fields are 
. transmitted .from" (eft to right. As shown in FIG. 3, in 
accordance with the invention, the Type field value of 
.IPCP is set .equal to 28 - representing the Non-Sharing 
QoS option message - and.the length field is set equal 

30 to 5 (the length of the Non-Sharing QoS a option mes- 
sage). Within IPCP, the following code values may be 
usedf 

Code = 2: long sequence number packet format 
35 with classes; and 

Code = 6: short sequience number packet format 
with classes. 

[0015] The NoCls field represents the number of 
40 classes on this particular link. Illustratively, eight classes 
are allowed. The QoS Bitmap field is a 1-byte bitmap 
(QoS bitmap) that is used to indicate the pres- 
ence/absence of a particular class number. (It should be 
noted that since the QoS Bitmap field is 8 bits wide - it is 
45 assumed that 8 PPP QoS classes "are sufficient 
(ciasses'6 - 7 with O a(s the highest priority class). Alter- 
natively, the QoS Bitmap field could be expanded to 
support more than 8 classes.) 

[0016] For example, in order for a PPP peer to com- 
50 municate to another PPP peer that there will be 3 
classes on this link, namely class 3, class 4, and class 
5, then the NoCls field is set to a value of 3, and the QoS 
Bitmap field is set to "0001 1 100" (where bit zero, or b 0 , 
is the leftmost bit)'. 
55 [0017] Finally, the Rsv field is reserved for future 
use. 

[0018] As a result of the above, during the IPCP 
negotiation phase (not shown), PPP peers can include 
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the newly defined Non-sharing QoS option message 
together with MRRU and End Point Discrirhinator 
Options. FIG. 4 illustrates use of the Non-Sharing QOS 
Option with standard Multiiink PIP. For convenience, in 
FIG. 4 it is assumed that the transmitting peer is Peer A 
and the receiving peer is Peer B (transmitting and 
receiving from the point of view of negotiation, e.g., Peer 
A requests the Non-Sharing QoS option:) As noted 
above, the Non-sharing QoS option message allows a 
PPP peer to specify the number of classes to be carried 
on a particular link.' For example, assumed a PPP peer 
first activates a link (link 1) using this Non-Sharing QoS 
option message and specifies that there will be two 
classes on link 1 , namely classes 3 and 4. (That is, the 
NoCis field is set to 2, and the QoS Bitmap field is set to 
"00011000.") Then, the PPP peer subsequently acti- 
vates 2 more links without enabling the Non-sharing 
QoS option (i.e., no Non-Sharing QoS option message 
was included in the negotiation phase for these addi- 
tional links). This means all PPP frames with class num- 
bers 3 and 4 will be carried over link 1, the rest of the 
PPP frames will be segmented/or fragmented, (as is 
done in multiiink PPP) and carried over the two remain- 
ing links (links 2 and 3) that were not negotiated with the 
Non-Sharing QoS option. Note that the bearer data 
(PPP frames) can use either the short or long sequence 
number fragment format with classes. 
[0019] It should be noted that it is assumed that if 
the Non-Sharing QoS option is negotiated, then the 
option applies for the traffic in both directions between 
the PPP peers. Using the example above, PPP frames 
with class numbers 3 and 4 will be carried over link 1 in 
either direction (also represented in FIG. 4 by the dou- 
ble-headed arrows for link 1). 

[0020] Turning now to FIGs. 5 and 6, and in accord- 
ance with the invention, illustrative formats for a new 
"QoS-Enhanced Muttilink Header Format (QoS-EMHF) w 
option message are shown. The fields are transmitted 
from left to right. The QoS-EMHF option message sup- 
ports the mapping of differentiated services (Layer 3) to 
PPP QoS classes. 

[0021] As can be observed from FIGs. 5 and 6, the 
Type field value of IPCP is set equal to 29 - representing 
the QoSrEMHF option message, and the length field 
value is set equal to the length of this particular QoS- 
EMHF option message and the Typ field value distin- 
guishes between one of two types. of QoS-EMHF option 
messages. (It should be noted that the Typ field sup- 
ports, four different types of QoS-EMHF option mes- 
sages, but only two are presently defined.) 
[0022] . A Typ field value of one. is illustrated in FIG. 
5. This type of QoS-EMHF option message comprises 
the following fields: NoCP, : CIsNo, and a variable 
number differential service (DS) codepoint fields 
(DSCPs). The value of the NoCP field represents the 
number of DSCP codepoints that will be mapped to the 
class number specified by the value of the CIsNo field. 
(For a definition of DSCPs, see Definition of the differen- 



tiated Services Field (DS Field) in the IPv4" and IPv6 
Headers (RFC2474), Dec, 1 998.) 
[0023] ' A type 1 QoS-EMHF option message ena- 
bles PPP peers to map differential service codepoints to 

5 PPP QoS classes. This enables a PPP peer to appropri- 
ately mark the respective PPP frames. For example, 
assume that two PPP peers carry IP packets with multi- 
* pie DSCPs marked, namely DSCP Code 1 , DSCP Code 
2, DSCP Code 3 and DSCP Code 4. Assume that it is 

■to"'' desired to map DSCP Code 1 and DSCP Code 2 to 
PPP QoS Class 1, and DSCP Code 3 and DSCP Code 
4 to PPP QoS Class 2. In the illustrated QoS-EMHF 
option message of FIG. 5 - the PPP peers inform one 
" another of this mapping with respect to so DSCP Code 

15 1 and DSCP Code 2, where CIsNo is equal to a value 
representative of class 1. A similar message (not 
shown) is also transmitted with respect to the assign- 
ment of DSCP Code 3 and DSCP Code 4 to Class 2 for 
another (ink. Without this option' both PPP peers may 

20 perform different mapping. Equipment from different 
vendors may not perform the same mapping and hence 
it is harder to provide QoS guarantees over a PPP/MP 
'link. 

[0024] It should be noted that when this option is 
25 "negotiated between peers, the accepting peer must 
transmit all IP packets marked with the respective 
DSCP values as PPP 'frames with the class number 
specified by the value of the CIsNo field in the QoS- 
EMHF option message. (For example, in FIG. 5, the 
30 accepting peer must transmit all IP packets marked with 
DSCP Code 1 and DSCP Code 2 with a class number 
oft.) If the receiving PPP peer cannot accept this map- 
ping, the receiving PPP peer will Configure-Nak or Con- 
figure- Reject the option back to the transmitting PPP 
35 peer. 

[00251 A Typ field value of two is illustrated in FIG. 
6. This type 2 QoS-EMHF option message comprises 
the following fields: NSeS, CIsNo, Session Len, and a 
variable number Session Description fields. The value 

40 of the NSeS filed represents the number of sessions 
that will use this PPP class number, which is specified 
by the value of the CIsNo field. The value of the Ses- 
sionLen field defines the length of a session description 
(4 bytes if it is IP destination, 5 bytes for IP destination + 

45 Protocol, 6 bytes for IP destination + Protocol + Port No, 
7 bytes for IP destination + Protocol + Port No + DSCP 
codepoint.) (in the context of Protocol and Port No., 
these terms are known in the art For example, the pro- 
tocol byte (not shown) is a predefined value that repre- 

50 sents either TCP (transaction control protocol) or UDP 
(User Datagram Protocol), similarly for Port No.) The 
illustrative QoS-EMHF option message of FIG. 6 repre- 
sents an NSeS value of 2, a Session Len value of 4, 
and, consequently, two Session descriptions, each of 

55 iength 4. 

[0026] For a type 2 QoS-EMHF option message, 
the description length of all sessions must be the same. 
When the QoS-EMHF type 2 option is negotiated, the 
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accepting, ,or receiving peer, must carry all IP packets 
with the specific session descriptions as PPP frames 
with class number specified in CIsNo field. If the receiv- 
ing. PPP peer cannot accept this mapping, it will Config- 
ure-Nakpr Configure-Reject the option under IPCR (it 5 
should be noted that specific ^packet endpoint imple- 
mentations provide sufficient buffer space to accommo- 
date the different classes of service* that they provide to 
each multilink PPP user) , ' 

[0027] Alternatively,- a QoS-EMHF optiqq. message JQ 
may be formatted as-shown in. FIG. .7. This.yer^qn of a , 4 . , 
QoS-EMHF option message cpfnbines-QpS-.EMHf type r ,. 
1 and QoS-EMHF type 2 information,. Th e ctsn o :s . - 
corresponds to. the PPP class numWr, the field, NoSD 
corresponds to the number of ^session-descripto/s assp- 15 . 
ciated with this, PPP QoS class. The Option Jyp fields 
Jiave values of; ■- . ., , 

OptionTyf^= 1 : .Session- Descriptor is D5CP code- 
• point (1, byte); ...... , . . ; . ~. , 20. 

. O ptio nTy p= 2: Sessio n Descripto r is . I P Desti natio n 
address (4 bytes); ... -*...,. ...... . , 

OptionTyp= 3: IP Destination Address + Port (5 . K} 
byte);. , - . , . . . . r l v 

.. OptionTyp= 4: IP Qestinatiqn Address * Port + Pro- 25 
tocoi ID (6 bytes);. and- . . . . , , : ^ 

OptionTyp= 5: IP Destination Address +. Port + Pro- 
tocol ID+DSCP Codepoint.(7 bytes). . , ^ 

[0028] : . It should be-noted that.other Optiqntyp infor- ,30 
mation may also be added, in FIG. 7, PPP ."class 1 
• (ClsNo = 1) has. a session descriptor being theDSCP 
code point (QptionType=1) and maps . 3 DSCP code 
points (DSCP #1 , DSCP #2, and DSCP #3) to this PPP 
Class Number. In addition, there is also a PPP'QIass 2 35 
(ClsNo = 2) with a session descriptor being the IP Des- 
tination address and maps packets for 2 IP destination 
addresses to this PPP Class Number. . 
[0029] , As a result of the above, the inventive con- 
cept provides a QoS mechanism within existing PPP 40 
that allows packets from some given sessions to be sent 
to one-physical link and packets from other sessions to 
be sent to another physical link. Further, it provides the 
exact class numbers that are activated at any particular 
time for admission control, radio resource management, 45 
and traffic engineering purposes. Finally, it provides the 
ability to map packets from one or multiple IP sessions 
into one of the wireless link in the link, bundle, in other 
words, a packet endpoint knows the exact types of the 
different classes that wilj be activated over any specific so 
link. 

[0030] Turning briefly to FIG. 8, a high-level block f 
diagram of a representative packet.endpoint for use in 
performing multilink PPP negotiation in accordance with 
the principles of the invention is shown. Packet endpoint 55 
605 is a stored-program-controi based processor archi- 
tecture and includes processor 650, memory 660 (for 
storing program instructions and data, e.g., for commu-. 



nicating in accordance with the above-mentioned modi- 
fied multilink PPP negotiation, etc.) and 
communications interface(s)*665 for coupling to one or 
more packet communication facilities as represented by 
path 666. 

[0031]. . The. foregoing merely illustrates the princi- 
ples of the invention and.it will thus be appreciated that 
those skilled in the art will be able to devise numerous 
altemative arrangements which, although hot explicitly 
described herein, embody the principles of the invention 
and are within its spirit and scope? 

Claims . ^ ^ 

1.. A method for use in a packet endpoint, the method 
. comprising the steps of: 

, negotiating ,'a, multilink point-to-point protocol 
(PPP) lihk with an opposite peer, wherein the 
negotiati.ng^step further comprises the step of: 

transmitting a message to the. opposite 
peer, where the message includes an iden- 
\ tification of a number of classes on a par- 
, ticular PPP link and each type of class on 
the particular PPP link. 

2. The method of claim 1 wherein the message 
includes a field representing the number of classes 
on the particular PPP link. 

3. The method of claim 1 wherein the message 
includes a field representing the type of each class 
on the particular PPP link. 

4. The method of claim 3 wherein the type of each 
class field comprises a number of bits, the value of 
each bit position being representative of whether or 
not a particular class is on" the particular PPP link. 

5. The method of claim 1 wherein the message is a 
"Non-Sharing QoS" option message. 

$. The method of claim 1 wherein the negotiating step 
further includes the step of transmitting a second 
message to the opposite peer, where the second 
message comprises information that ma'ps differen- 
tial service codepoints to a particular PPP class. 

7. The method of claim 6 wherein the second mes- 
sage comprises a class number field for'identifying 
the particular'PPP class, and at least one field the 
value of which represents the number of differential 
codepoint* values mapped to the particular PPP 
class. 

8. " The method of claim 6 wherein the second mes- 

sage comprises a class number field for identifying 



9 



EP 1 067 746 A2 



the particular PPP class, a codepoints field for iden- 
tifying the number of differential codepoint values 
mapped to the particular PPP class, and a number 
of fields equal to the value of the codepoints field, 
where each of the number of fields identifies a par- 5 
ticular differential codepoint value. 

9. The method of claim 6 wherein the message is a 
"QoS-Enhanced Multilink Header Format" option 
message. - * to 

10. The method of claim 1 wherein the negotiating step 
further includes the step of transmitting a- second 
message to the opposite peer, where the* second 
message comprises information identifies the is 
number of sessions that will use a particular PPP 
class. V ' 

11. The method of claim ib.wherein the secQnd mes- 
sage comprises a class number field for identifying 20 
the particular PPP class, and at least one field the 
value of which represents the number of sessions 
using the particular PPP class. 

12. The method of claim 10 wherein the second mes- 2s 
sage comprises a class number field for identifying. . ; , 
the particular PPP class, a number of sessions 
field, the value of which identifies the number of 
sessions using the particular PPP class, , and a • 
number of fields equal to the value of the number of 30 
sessions field, where each* of the number of ses^ 
sions fields provides a description of that session. 

13. The method of claim 10 wherein the message is a 
"QoS-Enhanced Multilink Header Format" option 35 
message. 
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